Operating Terminal of an Agricultural Machine with Hypervisor Software

ABSTRACT

The invention relates to an operating terminal ( 2 ) of an agricultural machine. The aim of the invention is to further develop the operating terminal. This is achieved in that hypervisor software ( 6 ) is installed onto the operating terminal ( 2 ), said software abstracting guest systems connected to the hypervisor software and the application software contained in the guest systems from the computer hardware ( 4 ). The software also regulates the communication between the guest systems and attributes computing time of the computer hardware ( 4 ) to the guest systems. The hypervisor software ( 6 ) is configured to have a system architecture consisting of the guest systems G 2  to Gn as the basis for the application software of the manufacturer of the operating terminal and/or driver for interfaces which are not to be provided to other partitions, Gx as the basis for security-critical application software, G y  as the basis for other interfaces of drivers which are to allow the remaining guest systems, with the exception of the guest system Gx, access to different computer hardware and software interfaces, and G 1  for retrofitting and installing an additional complete guest system including the application software contained therein.

The present invention concerns an operating terminal of an agriculturalmachine with computer hardware and computer software for operating theelectrical and/or electronic functions of the connected agriculturalmachine.

Operating terminals of the aforementioned kind are disclosed, forexample, in the publications DE 20 2008 007 912 and DE 20 2012 006 899.An operating terminal may be an agricultural terminal that is fixedlyinstalled in a tractor or a self-propelled work machine or that isretrofitted into a driver's cabin for operating the tractor, theself-propelled work machine and/or an implement. The implement may be atowed agricultural machine, an agricultural attached implement, or anagricultural sensor. An operating terminal can be used for control offunctions of a self-propelled work machine or a tractor as agriculturalmachines, or the operating terminal is used for controlling a differenttype of machine to be retrofitted to a tractor or carrier machine. Theoperating terminals are not only produced and programmed bymanufacturers of self-propelled work machines or tractors but also bymanufacturers of attached implements, for example, baling presses,mowing devices, turners, swathing devices, sowing devices, fertilizingand spraying devices, machines for working the soil, and the like sothat, by means of the operating terminal and the application softwareinstalled therein, functions of the self-propelled work machine, atractor, or an attached implement can be controlled.

In connection with agricultural machines there is the problem thatfrequently they can be operated optimally only by use of additionalapplication software. The operating functions of this applicationsoftware surpass the functional range that the software programs withapplication software, installed by the manufacturer in the operatingterminal for operating the electrical and electronic basic functions ofthe respective agricultural machine, offer. The additionally requiredapplication software may concern the areas of logistics, documentation,business management optimization, or precalculation for configuration ofthe agricultural machine. Also, assisting application software such aschat, email or navigation programs are popular.

The operating terminals which are put on the market by the manufacturersusually are closed systems in regard to the computer software and onlythe software programs installed by the manufacturer can be run on them.A retrofitting installation of application software of externalmanufacturers that supplements the package of application softwareinstalled by the manufacturer is not possible, in particular for safetyreasons. Accordingly, the utilizable functions of an operating terminalare limited to functions that the manufacturer has provided byinstallation of manufacturer's application software on the operatingterminal. Accordingly, the possibility of expanding the functionality ofthe operating terminal for the customer by retrofitting installation ofapplication software is not available. Accordingly, the agriculturalmachine cannot be operated with maximum efficiency and additionaldevices must be installed on the agricultural machine for running thecorresponding application software when the desired function is to beutilized during operation of the agricultural machine. Therefore, itoften happens that several operating devices are installed adjacent toeach other in the driver's cabin of an agricultural machine, forexample, adjacent to the operating terminal of the tractor manufactureranother operating terminal for an attached machine, a navigation device,and a data logger for documentation and accounting purposes, even thoughit would be possible to cover all functions with the hardware of asingle operating terminal.

It is the object of the present invention to further develop theoperating terminal such that it provides the possibility ofretrofitting, installing, and running application software beyond themanufacturer's limits, beyond the configuration with computer softwareat the time of delivery, without the operating terminals being impairedwith respect to the function predetermined by the manufacturer. Afurther object of the invention is to enable parallel operation andsimultaneous execution of safety-critical and safety-uncriticalapplication software on an operating terminal. A further object of theinvention is finally to enable development and installation ofapplication software substantially independent of the target platform,i.e., the concrete operating terminal, with the goal of fast andrisk-free migration.

The object is solved for an operating terminal of the aforementionedkind in that on the operating terminal a hypervisor software isinstalled that abstracts the connected guest systems and the and theapplication software contained therein from the computer hardware,controls the communication between the guest systems, and allocatescomputing time of the computer hardware to the guest systems, whereinthe hypervisor software in regard to its system architecture isconfigured for guest systems

-   -   G₂ to G_(n) as a basis for the application software of the        manufacturer of the operating terminal and/or drivers for        interfaces that are not to be made available to other        partitions,    -   G_(X) as a basis for safety-critical application software,    -   G_(Y) as a basis for additional interface drivers which is to        enable the other guest systems, with the exception of the guest        system G_(X), the access to different computer hardware and        software interfaces, and    -   G₁ for retrofitting and retro-installation of an additional        complete guest system including the application software        contained therein.

The hypervisor software is referred to by experts also as a virtualmachine monitor, abbreviated VMM. A hypervisor refers to a class ofsystems of practical computer science which serves as an abstractinglayer between actually existing hardware and an operating systempossibly already installed on the system and additional operatingsystems to be installed. Such systems make it possible to define avirtual environment of the hardware resources, in particular of the CPU,the memory, the space on the hard disk, and/or the available periphery,that serves as a base for the installation of guest operating systemsindependent of the actually existing hardware. A hypervisor enables theoperation of several guest systems on a host system. The hypervisoradministers the resource allocation for the individual guest systems. Itdistributes the hardware resources in such a way that resources areavailable as needed for each individual guest operating system as ifonly one operating system were present. This can be done by hardwareemulation, hardware virtualization, or paravirtualization. In thiscontext, the hypervisor virtually creates for each individual guestsystem its own complete computer with all hardware elements such as theprocessor, drives, working memory etc.

With the system architecture according to the invention of a hypervisorsoftware the objects of the invention are solved:

The guest systems G₂ to G_(N), G_(X) and G_(Y) as well as the hypervisorand the hardware are provided by the manufacture of the operatingterminal. A guest system is a complete operating system or a partitionwith greatly reduced application range.

The guest systems G₂ to G_(N) serve as a basis for the applicationsoftware of the manufacturer of the operating terminal as well as, wherenecessary, as drivers for interfaces that are not to be made availableto other partitions but may exclusively be used by the respective guestsystem. The number of employed guest systems is up to the respectivemanufacturer.

The guest system G_(X) serves as a basis for safety-critical applicationsoftware and contains all required interface drivers for thesafety-critical software applications. In general, this is at least oneCAN bus driver which enables other guest systems access to therespective interface, in particular the CAN bus, by means of aninterface. As needed, this can also be realized only within a limitedrange.

The guest system G_(Y) serves as a basis for additional interfacedrivers which enable the other guest systems, with the exception ofG_(X), access to different hardware and software interfaces. This canbe, for example, Ethernet, RS232, but also WLAN, LIN, and Bluetooth. Thecontrol of the display and of the touch screen would also be possible.

The architecture enables retrofitting/retro-installation of a completeguest system G₁ inclusive of the contained application software. Forthis purpose, it must provide a uniform interface for communication withthe partitions G_(X) and G_(Y) by means of the hypervisor, inasmuch asthe application software requires access to the respective hardwareinterfaces. Due to the secured separation of the guest systems G₁ toG_(N), G_(X), and G_(Y) by means of the hypervisor with regard to memoryand computing time, no application software of the guest system G₁, forexample, the application 1.A, can disturb the execution of theapplication software of the operating terminal manufacturer, forexample, the application 2.B.

The separation of safety-critical and safety-uncritical applications ona system is fulfilled as a result of the safe separation of theindividual partitions by means of the hypervisor.

A substantial independence of the applications from the hardware isrealized by the hypervisor. Accordingly, when exchanging the hardware,the hypervisor and, where necessary, the respective interface drivers inthe guest systems must be adapted in essence.

In the configuration of the system architecture according to theinvention, operating terminals can be supplemented in a simple way andwithout posing a risk to safety even by retrofitting with applicationsoftware of manufacturers other than the manufacturer of the operatingterminal. For example, the operating terminal preinstalled by thetractor manufacturer is provided with the hypervisor software andcomprises the partitions G₂ to G_(N), G_(X), and G_(Y). When themanufacturer of an attachable implement requires that, for optimaloperation and utilization of his implement, additional applicationsoftware, for example, the applications 1.A and 1.B, beyond theapplication software that is supplied by the tractor manufacturer beprovided on this operating terminal, the implement manufacturer, whenusing the system architecture according to the invention on theoperating terminal, has the possibility of offering the customer hisapplication software on the operating terminal of the tractormanufacturer by retrofitting the guest system G₁ with the applicationsoftware for the applications 1.A and 1.B, without the execution of theapplication software of the operating terminal originating from thetractor manufacturer being impaired. This is only possible so simplybecause no direct access of the guest systems installed on the operatingterminal to hardware interfaces can occur but an abstraction by theguests systems G_(X) and G_(Y) is realized. For the software developerof the applications 1.A and 1.B it is thus inconsequential whetheradditional application software unknown to him is accessing the sameinterfaces. This is frequently the case in particular for the CANinterface in connection with ISOBUS-compatible application software inagricultural technology.

By use of the system architecture according to the invention with thesecured separation between guest systems, the manufacturer of theoperating terminal can simultaneously run safety-critical as well assafety-uncritical application software on the same operating terminalwithout having to suffer limitations with regard to safety. For example,an application software of the guest system G₁ with application 2.Ashall be a chat application which enables the operator to receivemessages from a central logistic site which coordinates the sequence ofwork in a fleet. At the same time, on the guest system G_(X) anapplication software may be running that is classified and developed assafety-critical which, for example, monitors a mowing device that isattached to a tractor. A possible error in the chat application remainslimited to the guest system G₁ and in the worst case can lead tocomplete failure of the guest system G₁ but without impairing monitoringof the mowing device in the guest system G_(X).

When using the system architecture according to the invention, themanufacturer of an operating terminal can also exchange the hardware ofthe operating terminal quickly and with low risk for a new, morepowerful or otherwise better suitable hardware. The development cyclesfor agricultural operating terminals become shorter and shorter inanalogy to the existing trend in the consumer area. Up to now, anextreme expenditure is required by the manufacturer for migratingexisting application software onto a new, more powerful, or for otherreasons better suited, hardware. In view of this background, for themanufacturer of the operating terminal it is particularly important inregard to an exchange of the hardware to have to perform only little orno adaptations at all in regard to the application software in order tosave in this way significant expenditures and thus costs. The use of thepresented system architecture makes this possible and limits theadaptation expenditure to the hypervisor and, where necessary, thedrivers for the hardware interfaces in the guest systems. Theapplication software and the guest systems without direct access to thehardware interfaces, i.e., the guest systems G₁ and G₃ to G_(N) must notbe adapted in general.

According to one embodiment of the invention, the hypervisor software inits system architecture is configured for several guest systemsG₁₋₁-G_(1-N) for retrofitting and retro-installation of a respectiveadditional complete guest system including the application softwarecontained therein. Due to the configuration of the hypervisor softwarefor retrofitting several guest systems, the flexibility and adaptabilityof the operating terminal in regard to different functional optionsdesired by the customer increase.

According to an embodiment of the invention, the application software ofthe guest system G₁ has only an indirect access to the safety-criticalfunctions of the hardware via the hypervisor and the guest system G_(X).In this system architecture, at least via the application software ofthe retrofitted guest system G₁, no direct access to the hardwareinterfaces of the operating terminal is realized so that functionalrisks for safety-critical functions of the computer software installedby the manufacturer is precluded by means of an abstraction by the guestsystem G_(X).

According to an embodiment of the invention, the application software ofthe guest system G₁ has only an indirect access to safety-uncriticalinterface drivers of the hardware via the hypervisor and the guestsystem G_(Y). In this system architecture, at least by the applicationsoftware of the retro-installed guest system G₁, no direct access tosafety-uncritical interface drivers of the hardware of the operatingterminal is realized so that here also functional risks for functions ofthe computer software installed by the manufacturer is precluded bymeans of the abstraction by the guest system G_(Y).

According to an embodiment of the invention, the guest system G₁ is acontrol program for controlling an agricultural implement. Byorganization of the communication of a guest system G1 with theoperating terminal by means of a hypervisor software, it is possiblewithout safety risks for safety-critical functions to retro-install andoperate the software for control of an agricultural implement on anexisting operating terminal without this requiring installation ofseparate operating terminals in the driver's cabin.

It is expressly noted that the afore described advantageous embodimentseach can be combined in any combination with the subject matter of theindependent claim but also with other advantageous configurations,inasmuch as no technical obstacles stand in the way.

Further modifications and embodiments of the invention can be taken fromthe following subject matter description and the drawings.

The invention will be explained in more detail with the aid of anembodiment.

FIG. 1 shows an example of a system architecture according to theinvention. The dashed line delimits the operating terminal 2 that ismanufactured by the original manufacturer and delivered to customers.The operating terminal 2 comprises the computer hardware 4 which isinstalled therein and is illustrated in a simplified manner as a box, onwhich the hypervisor software 6 is implemented which is also illustratedin a simplified way as a box.

The operating terminal 2 comprises in the embodiment also the guestsystems G₂-G_(N) that form the basis for the application software of themanufacturer of the operating terminal 2 as well as, where necessary, asdrivers for interfaces that are not to be made available to otherpartitions but may only be used exclusively by the respective guestssystem. The guest systems G₂ to G_(N) can have access by means of path12 to exclusive interfaces, for example, a special RS232 connector, asillustrated in the embodiment for the guest system G₂.

The guest system G₁ is a retrofitted guest system that containsapplication software for all additional applications that are required,or may only be advantageous, for operation and control of the machineconnected with this guest system G₁. The guest system G₁ does not accessdirectly the hardware 4 of the operating terminal 2, the access isrealized only indirectly by means of the hypervisor 6 and the guestsystems G_(X) and G_(Y) connected thereto and provided by themanufacturer of the operating terminal 2. In the embodiment, the guestsystem G_(X) for safety-critical applications accesses directly throughpath 8 the hardware 4, for example, accesses a CAN bus as a component ofthe hardware 4, and the guest system G_(Y) for common drivers accessesthrough path 10 the hardware 4, for example, for an access to otherinterfaces such as Ethernet, WLAN, or Bluetooth.

The function of the communication of the different guest systems witheach other as well as the access to the hardware interfaces of otherguest systems to the hardware 4 of the operating terminal 2 by means ofhypervisor software 6 will be explained in more detail with thefollowing examples.

The application A.1 in the guest system G₁ requires information/datafrom the CAN bus and wants to send itself information or data to the CANbus. The communication of the application A.1 in the guest system G₁with the CAN bus is realized by path 14 which is formed in theembodiment as a generic bidirectional communication interface to thehypervisor 6. This communication interface provides a direct connection,point to point, between the guest systems G₁ and G_(X) on whichexclusively CAN bus data are exchanged. For additional interfaces, forexample, Ethernet, an additional generic communication interface wouldhave to be realized in the same way, for example, by the path 16 fromguest system G₁ to guest system G_(Y).

In order to send data to the CAN bus, the application A.1 in the guestsystem G₁ first sends data to the generic interface on the hypervisor 6.The hypervisor 6 receives the data and communicates them through aninterface to the guest system G_(X). This communication path correspondsto path 14 in FIG. 1. The guest system G_(X) receives the received dataand communicates them on path 8 to the CAN bus driver which is acomponent of the hardware 4. The CAN bus driver itself then takes overthe actual sending action of the data on the CAN bus.

Receipt of CAN bus data happens exactly opposite: The CAN bus driver ofthe hardware 4 receives the data from the CAN bus network andcommunicates them to the guest system G_(X). The guest system G_(X)communicates the data subsequently via the generic communicationinterface of the path 14 of the hypervisor 6 which, in turn, thencommunicates the data to the guest system G₁. In the guest system G₁ theCAN bus data are made available to the application A.1.

In order to avoid unnecessary load on the processor by the communicationbetween the different guest systems G₁ and G_(X) through the hypervisor6, only the data that are required by application A.1 are communicatedthrough the hypervisor 6. The application A.1 informs for this purposethe guest system G_(X) of the required data in the form of anidentification. In the context of ISOBUS communication, a meaningfulidentification is “parameter group number” (PGN) for which regulationsare available in the standards ISO11783 and J1939. In this case, theguest system G_(X) or the CAN bus driver would communicate only therequested, i.e., the needed, PGNs via the hypervisor 6 to the guestsystem G₁.

In analogy, the same concept also applies to the access of the guestsystem G_(X) to other hardware interfaces. In particular thecommunication is possible in a similar way with an Ethernet-basednetwork but requires system-based adaptations. Moreover, the access tohardware interfaces of the guest system G_(Y) by applications of theguest system G₁ is realized in a similar way.

The communication explained herein by means of the hypervisor 6 betweenan application in the guest system G₁ with the CAN bus which isconnected to the guest system G_(X) functions also for applications ofother guest systems that want to access the hardware 4 forsafety-critical applications, for example, by path 20. Also, as needed,the communication by means of hypervisor 6 between different guestsystems G₂-G_(N) among each other can be realized by an appropriate path18.

For analog hardware interfaces that are connected, for example, to guestsystem G_(Y), they are first converted by the guest system G_(Y) intodigital values and interpreted. The interpreted values are then madeavailable by means of a generic communication interfaces via the path 16to the guest system G₁.

For certain data, a unidirectional communication interface may besufficient. In this case, the guest system G_(Y) communicates the datato a unidirectional hypervisor interface that can be read by severalguest systems. In this way, several bidirectional communicationinterfaces via the hypervisor 6 are avoided and the data are efficientlymade available to the guest systems.

The invention is not limited to the afore described embodiment. A personof skill in the art will have no problem in modifying the embodiment ina way that appears suitable in order to adapt it to a concreteapplication situation.

What is claimed is:
 1. Operating terminal (2) of an agricultural machinewith a computer hardware (4) and a computer software for operating theelectrical and/or electronic functions of the connected agriculturalmachine, characterized in that on the operating terminal (2) ahypervisor software (6) is installed that abstracts guest systemsconnected thereto and the application software contained therein fromthe computer hardware (4), controls the communication between the guestsystems, and allocates computing time of the computer hardware (4) tothe guest systems, wherein the hypervisor software (6) in its systemarchitecture is configured for guest systems G₂ to G_(n), as a basis forthe application software of the manufacturer of the operating terminaland/or drivers for interfaces that are not to be made available to otherpartitions, G_(X) as a basis for safety-critical application software,G_(Y) as a basis for additional interface drivers which is to enable theother guest systems, with the exception of the guest system G_(X), theaccess to different computer hardware and software interfaces, and G₁for retrofitting and retro-installation of an additional complete guestsystem including the application software contained therein. 2.Operating terminal (2) according to claim 1, characterized in that thehypervisor software (6) in its system architecture is configured forseveral guest systems G₁₋₁-G_(1-n), for retrofitting andretro-installation of a respective additional complete guest systemincluding the application software contained therein.
 3. Operatingterminal (2) according to claim 1, characterized in that the applicationsoftware of the guest system G₁ has an indirect access to thesafety-critical functions of the hardware (4) only via the hypervisor(6) and the guest system G_(X).
 4. Operating terminal (2) according toclaim 1, characterized in that the application software of the guestsystem G₁ has an indirect access to safety-uncritical interface driversof the hardware (4) only via the hypervisor (6) and the guest systemG_(Y).
 5. Operating terminal (2) according to claim 1, characterized inthat the guest system G₁ is a control program for controlling anagricultural device.